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Framework  which  considers  the  affects  of  security 
threats  on  complex  operational  business  processes. 
He  is  a  coauthor  of  the  book  “Software  Security 
Engineering:  A  Guide  for  Project  Managers” 
(Addison-Wesley  2008) 
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Polling  Question  #1 

How  did  you  hear  about  this  webinar? 

i. Social  Media  (i.e.,  Linkedln,  Twitter) 

2.SEI  Website 

3.SEI  Member  Bulletin 

4.Email  invitation  from  the  SEI 

s.Website  with  webinar  calendar  (i.e..www.webinar- 
directorv.com) 
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Software  Supply  Chain 


The  network  of  stakeholders  that  contribute  to  the 
content  of  a  software  product  or  that  have  the 
opportunity  to  modify  its  content. 

Comprehensive  National  Cybersecurity  Initiative  1 1 
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Polling  Question  #2 


Has  your  organization  had  a  problem  with  software 
malware  in  the  last  year? 

Answers: 

•  Yes 

•  No 

•  Do  not  know 
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What  We  Will  Cover 

Software  supply-chain  complexity:  slides  6-8 
Strategy:  slides  10-18 
Supply-chain  risk  example  20-40 
Summary:  slides  42-44 
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Supply-Chain  Risk  Examples 

Hardware 

•  Manufacturing  and  delivery  disruptions 

•  Manufacturing  quality 

•  Counterfeit  hardware  estimated  at  10% 

•  Decades  of  data  collection  for  physical  supply  chains 

Software 

•  Third-party  tampering  during  development  or  delivery 

•  Malicious  supplier 

•  Compromised  by  inadvertent  introduction  of  exploitable 
design  or  coding  errors 

•  Very  little  data  for  software  supply  chains 

Software  Engineering  Institute  CarntgieMelkm  7 


Software  Supply  Chain  Complexity1 
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Composite  inherits  risk  from  any  point 
in  supply  chain 

Poor  Visibility:  Incomplete  information 
Output:  One-off  software  components 
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The  Landscape  Complexity-3 


ICT  SCRM 
Standards 
Landscape 


KEY 

International  Standards  Body 

National  Standards  Body 

Other  Organizations 

Technical  Committees/ 
Other  Standards  Bodies 

ISO,  IEC.  and  ITU 
\ f  Subcommittees 


Liaison  Relationship 
with  SC7 


Liaison  Relationship 
with  SC27 


Systems  and  Software  Technology  Conference  2010,  Don  Davidson,  Globalization  Task  Force,  DoD 


r\ 

(cert 


Software  Engineering  Institute  Carnegie  Mellon 


9 


Strategy 
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Propagation  of  Supply-Chain  Risks 


Selection 


Evidence 
of  Secure 
Software 


Integration 


Deployment 
Over  time 


Construction 

Secure  Development 
Practices 

Governance 

Training 

Supplier  and 

subcontractor 

management 

Verification  of  third- 
party  software 


Supplier  and 
independent 
verifications 

Used  recommended 
mitigations  from 
CWE 

Weaknesses  and 
mitigations  tested 

Systematic  testing  of 
invalid  input 

Static  analysis  of 
source  code 


Mitigation  of  risks 
not  adequately 
addressed  by 
supplier 

Effects  of 

component  supply- 
chain  risk  on 
aggregate  system 

Risks  induced  by 
integration: 
Assumption 
mismatches 

Verify  that 
aggregate  risk  is 
still  acceptable 


Install  supplier 
updates 

Periodically  update 
risk  assessment: 
changes  in  usage, 
attack  patterns, 
product  updates, 
suppliers 

Monitor  operational 
system  behavior  for 
unexpected  events: 
test  of  design 
assumptions 
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Information  Needs  by  Activity 

Evidence  of 

Selection  Secure  Integration  Deployment 


Relative  Effort 


Knowledge  of 
Supplier  Capabilities 


Knowledge  of 
Product  Attributes 


Operational  Capabilities 
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Supply-Chain  Risk  Categories 


Category 

Description 

Acquirer  Capability 

Operational  preparedness,  acquisition  task  execution, 
event  management 

Supplier  Capability 

Governance,  Construction,  Verification,  Deployment 

Product 

An  assessment  of  the  problems  and  issues 
associated  with  a  software  product 

Product  Logistics 

Access  control  of  the  software  product  at  each  step  in 
the  supply  chain 

Operational  Product  Control 

Implementation  of  appropriate  operational 
configuration  and  monitoring  controls  to  reduce  the 
risk  of  unauthorized  changes  to  software  products 

CERT  Software  Engineering  Institute  Carnegie  Mellon  13 


Strategy  Outline-1 

A  solution  depends  on  a  combination  of 

•  Supplier  capabilities  to  create  secure  software 

—A  necessity 

•  Product  verification 

—What  evidence  shows  that  supplier  expertise  has  been 
effectively  applied  to  produce  more  secure  software? 

•  Acquirer  capabilities 

—Capability  to  manage  multiple  suppliers 
—  Match  software  usage  with  supplier’s  intent 
—  Manage  changes  in  usage,  suppliers,  and  attack  patterns 
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Strategy  Outline-2 


Acquirer  has  to  plan  for  security  after  deployment 

•  No  guaranteed  way  to  find  maliciously  inserted  code 

•  Supply  chain  risk  assessment  can  be  invalidated  by 

—  New  attack  techniques  and  software  weaknesses 

—Changes  in  acquirer  usage  that  activate  unused  product 
features 

Product  upgrades  that  add  features  or  change  implementation 

—  Increase  in  criticality  with  new  or  expanded  usage 

—Changes  in  the  supplier  risk  factors:  mergers,  corporate 
policies,  staff  training,  development  life  cycle 

•  Operational  management  has  to  deal  with  incomplete 
supplier,  product,  and  attack  risk  information 
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Polling  Question  #3 


Does  your  organization  consider  a  vendor’s 
capabilities  to  produce  secure  software  when 
purchasing  COTS  software  or  outsourcing  software 
development? 


Answers: 

•  Yes 

•  No 

•  Do  not  know 
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SEI  Project 


Supply  Chain  Risk  Model 

•  Develop  a  model  that  helps  to  structure  and  simplify 
analysis 

•  Initial  focus  on  software  supply  chain 

•  Software  supply  chain  risk  management  is  more  than  a 
supplier  assessment 

—  Manage  supply-chain  risks  that  continue  into  deployment 

—  Need  increased  understanding  of  allocation  of  responsibilities 
among  suppliers  and  acquirers 
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Supply  Chain  Drivers 


A  systemic  risk  assessment  is  based  on  a  small  set 
of  factors  that  strongly  influence  the  eventual  out¬ 
come  or  result. 

These  factors  are  commonly  referred  to  as  drivers. 

SEI  experience  shows  that  about  15-25  drivers  are 
needed  to  establish  a  comprehensive  profile  of 
systemic  risks  to  mission  success. 

These  drivers  reflect  both  supplier  and  acquirer 
factors. 
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General  Set  of  Supply-Chain  Drivers 


1 .  Software  Supply-Chain 
Objectives 

2.  Acquisition  Plan 

3.  Contracts 

4.  Development  Process 

5.  Acquisition  Task  Execution 

6.  Coordination 

7.  Software  Supply-Chain 
Interfaces 

8.  Information  Management 

9.  Technology 

10.  Facilities  and  Equipment 

1 1  .Environmental  Conditions 

Software  Engineering  Institute  CaraegicMdkin 


12.  Compliance 

13.  Event  Management 

14.  Requirements 

15. Architecture 

16.  Design,  Code,  and  Test 
17. System  Functionality 
18. System  Integration 
19.0perational  Support 
20.Adoption  Barriers 

21  .Operational  Preparedness 
22. System  Risk  Tolerance 
23. Certification  and  Accreditation 
24. Sustainment 


Software  Supply-Chain 
Risk  Example 
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A  Supply-Chain  Weakness 


Existing  vulnerabilities  present  easy  and  effective 
opportunities  for  attackers  -  errors  support 
malicious  activities 

Can  reduce  likelihood  of  vulnerabilities  with 
incremental  changes  in  development  practices 

•  Draw  from 

—  Microsoft’s  Secure  Development  Life  Cycle 

-SAFECode 

Build  Security  In  Maturity  Model  (BSIMM) 

—  Build-Security-In  https://buildsecurityin.us- 
cert.gov/daisy/bsi/home.html 
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Prevalence  of  Software  Errors 


MITRE  has  documented  software  errors  that  have  led 
to  exploitable  vulnerabilities:  Common  Weakness 
Enumeration  (CWE) 

CWE/SANS1  Top  25  Most  Dangerous  Programming 
Errors  published  yearly  by  MITRE  -  3/1/2010 


Examples 


Improper  Input  Validation 

Cross-site  scripting 

Download  of  Code  Without  Integrity 

Check 

Race  Condition 


SQL  Injection 

Use  of  Hard-coded  Credentials 

Improper  Check  for  Unusual  or 
Exceptional  Conditions 

Classic  Buffer  Overflow 


1.  http://cwe.mitre.org/top25/ 

SANS  (SysAdmin,  Audit,  Network,  Security)  Institute 
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Veracode:  State  of  Software  Security 

58%  of  all  applications  did  not  achieve  an  acceptable 
security  score  upon  first  submission  -  3/1/2010 

Measured  Against  CWE/SANS  Top-25  Errors 


Software  Source 

Acceptable 

Outsourced 

6% 

Open  Source 

39% 

Internally  Developed 

30% 

Commercial 

38% 

Veracode:  The  pervasiveness  of  easily  remedied 
weaknesses  suggests  developer  training  for  secure 
software  development  is  a  critical  supplier  criteria. 

—  Software  Engineering  Institute  CurncgicMdien 
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SQL  Database  Query 


User  Input 

48983 


Output:  All  records  with  ID  =  48983 

48983  Sally  Middleton  $74,210 


Could  involve  multiple  supply  chains:  web  server,  SQL 
database,  and  contracted  software  development 
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CWE-89:  Attacker  View  -  SQL  Injection 


CWE:  116  Use  Output  Encoding  or 
Escaping  “48983  OR  (1  =  1)” 

SQL  commands  in  quotes  are  not 
executed 


Attack 

Enabler 


Process 

Input 


SQL 

1  Attack 

Database 

|  Target 

SQL 

Commands 


Channel  :AttackerAccess 


48983  OR  (1  =1) 

Data  SQL  Command 
Invalid  Input 


Output:  All  records  where  ID  =  48983 
OR  where  (1=1) 

All  Employees 


CWE-20:  Input  validation 

CWE-89  Sanitize  Special  Elements  used  in  an  SQL  Command 
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Assessments  By  Activity 


Selection 


Relative 

Effort 


Construction 

Secure  Development  Practices 

Governance 

Training 

Supplier  and  subcontractor 
management 

Verification  of  third-party  software 


Knowledge  of  Knowledge  of 

Supplier  Capabilities  Product  Attributes 
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Driver:  Design,  Code  and  Test 


Is  the  code’s  quality  sufficient  to  meet  system  requirements  and 
provide  the  desired  operational  capability 


Design  reviews 

Source  code  reviews 

Coding  practices 

Static  code  analysis 

Unit  and  integration  testing 

Analysis  of  common 
weaknesses 


Analysis  of  attack  patterns 
Threat/vulnerability  analysis 
Software  security  testing 
Dynamic  testing 

Code  interfaces  and  dependencies 
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Evidence  of  Secure  Software 


Selection 


Verification 


Relative 

Effort 


Evidence  of  Secure  Software 

Supplier  and/or  independent  verifications 

Used  recommended  mitigations 

Likely  software  weaknesses  and 
mitigations  tested 

Systematic  testing  of  invalid  input 

Static  analysis  of  source  code 


Knowledge  of  Knowledge  of 

Supplier  Capabilities  Product  Attributes 


Software  Engineering  Institute  Carnegie  Mellon 


28 


Product  Evidence:  Testing 


Security  Testing 

•  Potential  software  weaknesses  and  mitigations  tested 

•  Systematic  testing  of  invalid  input  -  fuzz  testing 

•  Static  analysis  of  source  code 

Testing  is  increasingly  automated  and  outsourced 

•  Limited  value  for  risk  analysis: 

—We  know  neither  the  consequences  or  likelihood  for  any 
remaining  vulnerabilities  nor  the  costs  and  effectiveness  of 
possible  mitigations 

•  Expensive  redesign  and  mitigations:  Veracode  statistics 
on  initial  failures  for  security  testing. 
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Product  Evidence:  Attackability 


Attack  Surface 


SQL 

Commands 


Attack 

Enabler 


SQL 
Database 


Attack 

Target 


Channel  :AttackerAccess 


A  system  with  more  targets,  more  enablers,  more  channels  or 
more  generous  access  rights  provides  more  opportunities  to  the 
attacker. 

Attack  surface:  targets,  enablers(  exploitable  features), 
communication  channels,  and  access  controls 

—  Software  Engineering  Institute  CurnegicMdien  30 


Using  Attack  Surface  Analysis 


Reduce  Attack  Surface 

•  Remove  or  change  system  features  or  re-architect  the 
implementation  to  avoid  attack  enablers  or  unnecessary 
channels. 

•  Revise  use  of  an  emerging  technology  where  there  is 
limited  knowledge  of  the  potential  exploits  and 
mitigations 

•  Review  requirements  or  implementation  if  existing 
mitigations  are  costly  or  do  not  provide  the  necessary 
assurance 
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Data  Flow  Analysis 


SQL 

Commands 


Use  Output  Encoding  or  Escaping 
Quote:  “48983  OR  (1  =1)” 


Process 

Input 


48983  OR  (1  =  1) 


SQL  Command 
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Display 

Output 


All  Employees 


Input  validation 

Sanitize  Special  Elements  used  in  an 


Data  flow  analysis 

•  Identify  sources  of 
vulnerabilities:  Mix  of  data  and 
commands 

•  Consider  consequences 

•  Analyze  mitigations 

•  Provide  architecture  and 
design  guidance 
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Data  Flow  Analysis  Benefits 

Supports 

•  Objective  trade-off  discussions  involving  security  risks 
during  initial  development  or  with  later  upgrades 

•  Supply-chain  risk  management  -  consequences  and 
mitigations 

•  Traceability  and  business  justifications 

•  System  integration  -  insight  into  design  assumptions, 
attack  patterns  considered  and  mitigation  strategy 

•  Operational  monitoring  -  design  assumptions  about 
expected  behavior 
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Threat  Modeling 


Threat  Modeling:  During  a  data  flow  walk  through 

•  Document  security  assumptions  and  trust  boundaries 

•  Consider  known  weaknesses  and  attack  patterns 

•  Consider  deployed  configuration  and  expected  usage 

•  Analyze  the  interfaces  to  other  components  (inputs  and 
outputs) 

•  Analyze  possible  mitigations 

Value  recognized  -  Microsoft’s  SDL,  BSIMM 
collection  of  current  practices  drawn  from  thirty 
firms 

See  Stevens  (references)  for  adoption  considerations 
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Driver:  Acquisition  Task  Execution 


Are  tasks  and  activities  performed  effectively  and  efficiently? 


Experience  and  Sufficient  experience  in  software 

expertise  of  security,  reliability,  and  safety 

management  and  staff  engineering 


Resources  allocated  to  Experience  with  software  supply 

tasks  and  activities  chains 
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Polling  Question  #4 


Do  your  suppliers  and  in-house  developers 
incorporate  threat  modeling  as  part  of  the 
vulnerability  analysis? 


Answers: 

•  Yes 

•  No 

•  Do  not  know 
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Incorporate  into  Acquisition1  RFP 


RFP:  ask  for  evidence 

•  Development  staff  training 

•  Documentation  of  potential  attacks  and  mitigations 

•  Supplier  capabilities  as  demonstrated  with  development 
of  other  systems 

•  For  contracted  development,  require  application  of  threat 
modeling  to  analyze  risks  associated  with  architecture 
and  design  decisions 
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Driver:  Contracts 


Are  the  contract  mechanisms  with  each  participating  group  or 
team  sufficient? 

Includes  suppliers  contracts  with  their  suppliers  or 
subcontractors 


Acquisition  and 
development  strategies 

Resources 

Funding 

Intellectual  property 
considerations 

Licensing  agreements 


Sufficient  focus  on  software 
security,  reliability,  and  safety 

Contracts  with  each  participating 
group  or  team 

Schedule 

Alignment  among  the  contracts 
of  participating  groups  or  teams 

Roles  and  responsibilities 
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Integration  and  Deployment 


Relative 

Effort 


Integrate:  Multiple 
Suppliers 


Deployment 


Over  time 


.ii 


Knowledge  of 
®  Supplier 
Capabilities 

Knowledge  of 
Product 
Attributes 

Operational 

Capabilities 


Mitigation  of  risks  not 
adequately 
addressed  by 
supplier 

Effects  of  component 
supply-chain  risks  on 
aggregate  system 

Risks  induced  by 
integration: 
Assumption 
mismatches 

Verify  that  aggregate 
risk  is  still  acceptable 


Install  supplier 
updates 

Periodically  update 
risk  assessment: 
changes  in  usage, 
attack  patterns, 
product  updates, 
suppliers 

Monitor  operational 
system  behavior  for 
unexpected  events: 
test  of  design 
assumptions 
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Driver:  System  Integration 


Will  the  system  sufficiently  integrate  and  interoperate  with  other 
systems  when  deployed? 


Interfaces 

COTS  software 

Applications 

Performance,  security,  reliability, 
and  safety  of  the  integrated 
system 

Tools 

Failure  analysis 

Hardware 

Security  testing 

Data 

Legacy  systems 
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Driver:  Event  Management 


Does  the  software  supply  chain  have  sufficient  capacity  and 
capability  to  identify  and  manage  potential  events  and 
changing  circumstances? 


Expected  and  unexpected 
potential  events  and 
changing  circumstances 

Changes  in  personnel  or 
suppliers 

Changes  in  product  usage 


Program  continuity,  disaster,  and 
contingency  plans 

Issue/problem  management  plan, 
process,  and  tools 

Changes  in  requirements 
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Summary 
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Manage  Supply-Chain  Risk 


Operational  Context,  e.g.,  usage, 
requirements,  operational 
preparedness,  risk  tolerance 

Acquisition  Scope,  e.g.,  product, 
system,  system  of  systems,  major 
upgrade,  component  replacement 

Supplier  Capability  Data,  i.e., 
guidance  for  supplier  evaluation 

Preliminary  Product  Data,  i.e., 
guidance  for  product  evaluation 

Supplier  Product  Development 
Information,  e.g.,  architecture,  design- 
code-test,  compliance,  supply-  chain 
interfaces,  event  management 

Acquirer  Information,  e.g.,  acquisition 
plan,  acquisition  task  execution,  event 
management 

Operational  Product  Control,  i.e., 
monitoring  and  configuration  control  of 
software  products 
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Acquisition 

Characteristics 


Drivers 


Supply  Chain 
Evidence 


Key  Risk 
Drivers 


Acquirer  Risk 
Mitigation  Actions 


M 

a 

n 

a 
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Summary 


Supplier,  acquirer,  and  operator  all  have  roles  to 
ensure  good  practices  are  applied! 

A  supply-chain  risk  model  helps  to  manage 
complexity  and  provides  a  structure  for  risk 
analysis 

Example:  Remove  widely  exploited  software 
weaknesses  with  known  mitigations 

•  Feasible 

•  Incremental  changes  to  existing  software  development 
and  acquisition  life  cycles 

•  Demonstrated  value 


r\ 

'CERT 


Software  Engineering  Institute 


Carnegie  Mellon 


44 


Sources 


Evaluating  and  Mitigating  Software  Supply  Chain  Security  Risks 
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www.sei.cmu.edu/sepg/europe/2010/ 


SEPG  is  the  premier,  global  conference  series  on 
software  ana  systems  process  management 
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Become  an  SEI  Member! 
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For  more  than  20  years,  the  SEI  has  been 
at  the  forefront  of  software  engineering. 

By  becoming  an  SEI  Partner,  you  join  forces  with  a  software 
engineering  pioneer  and  an  institute  whose  credibility  provides 
a  solid  foundation  during  uncertain  economic  times. 
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